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ABSTRACT 



A bar-code-driven data acquisition and management system 
includes at least two input computers, operably coupled via 
a communication link, each coupled to a respective local 
database of data records. The system includes at least two 
portable computing devices, each operably coupled to one of 
the two input computers via a wireless communication 
channel for accessing the data records of the local databases 
of the at least two input computers. Each portable computing 
device comprises a CPU, memory, and a touch sensitive 
display device that cooperate to display multiple virtual 
regions (which comprise on a data I/O screen and sense 
location of contact by a user in these virtual regions to 
thereby provide for user input These multiple virtual 
regions preferably include one of a virtual keypad for 
entering symbols associated with keys of the keypad, at least 
one scroll bar, at least one rolling key, multiple icons, a menu 
screen and a graphing screen. In addition, each portable 
computer has an integrated bar code reader for data entry. 
The information acquired and maintained by the system may 
include product information, information identifying a 
medical patient, or information related a medical patient 
(such as personal information gathered upon admittance for 
care, information related to past medical history of the 
medical patient, and information related to vital statistics of 
the medical patient). In addition, each portable device may 
include a message notification mechanism that notifies the 
user of receipt of a message from one of the input computers 
over the respective wireless communication channels. 

25 Claims, 17 Drawing Sheets 
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BAR-CODE-DRIVEN DATA ACQUISITION encounter similar problems. First and foremost, a significant 

AND MANAGEMENT SYSTEM amount of the field operative's time is required in filling out 

RELATED CASES the corr ssponding paperwork, in which the potential for user 

error exists. Also, in systems using paper forms, the infor- 

This Application is a Continuation of U.S. application Ser. 5 mation must be ultimately transferred to an electronic 

No. 09/241,214 filed Feb. 1, 1999, now U.S. Pat. No. database, which provides a second opportunity for user 

6,389,477; which is a Continuation of U.S. application Ser. error. Clearly, it would be advantageous to reduce the 

No. 08/196,452 filed Feb. 14, 1994, now U.S. Pat. No. number of user entries, thereby reducing the likelihood of 

5,867,688. Each said patent application is assigned to and error. 

commonly owned by Metrologic Instruments Inc. of 10 Further, in many markets, field personnel at one location 

Blackwood, N J., and is incorporated herein by reference in typically require information quickly from another field 

i s en ire y. location. For instance, in a hospital environment, a doctor 

BACKGROUND OF THE INVENTION within the general ward may require immediate information 

1 rr ia t *u t *• concerning a patient from the radiology department. 

1. Field of the Invention 15 However, the process under which the information is written 
The present invention relates in general to a system for down and carried between departments is very slow. 

data acquisition and retrieval through the use of a user Similarly, doctors and nurses require immediate and accu- 

interface remotely located from the control system. rate knowledge of specific procedures to be followed with 

2. Description of the Related Art regard to particular patients. Past systems for maintaining 
Today, most commercial businesses require field 20 mdividual patient procedures have proven ineffective. 

employees, such as at points of sale, to fill out paper forms Moreover, one office within a business will typically 

with data sets concerning individual customers or products require information from another office which must be hand 

sold/manufactured. These reports are then collected, com- carried or which is unavailable after the closing hours of the 

piled and assimilated at a central location and filed for future second office. For instance, hospitals require lab testing 

access. Most modern businesses require this information to results be hand-carried to doctors who may be waiting for 

be continuously updated and that the field personnel be such results during the course of surgery. Also, typically 

afforded quick access thereto in order to reduce business doctors require clinical data after the clinics have closed, 

costs, improve efficiency, increase accuracy, and the like. The need remains in this field for an improved data 

Heretofore, data sets concerning matters, such as customer 3Q acquisition and retrieval system to address the problems and 

or product information, have been primarily compiled drawbacks heretofore experienced. The primary objective of 

through paper forms completed by field personnel and later this invention is to meet this need, 
possibly entered into some form of central database. 

In the healthcare field, hospitals utilize a significant SUMMARY OF THE INVENTION 

amount of data retrieval and acquisition, with respect to 3S It is an object of the present invention to provide a data 

patient information. All data sets containing patient infer- acquisition and retrieval system which allows users imme- 

mation (data field), such as patient name (a data set, header), diate real time access to all existing customer/product infor- 

date of birth, place of business, address, phone numbers, mation 

language, billing account number social security number, It ^ an object of ^ invention ^ 

driven, license number, and the fcke were written on paper w acqllisition and retrieval P system which affoK £ ^ ^ 

hv? he hot ,r T , 1D 3 PaP6r h ?t ° Pti T Uy T eC t d t0 wireless remote terminals. 

by the hospital staff into a common database. Thereafter, the T , . , . . - 

patient information was supplemented with information , " * a ? °T of u mc P rescnt mvcntlon to minimize the 

pertaining to their health condition, such as vital signs, fluid ° ! lme b £ re f™ mg the necessar y information 

intake, fluid output and the like, which were written on A< transmitted between handheld units and the corresponding 

different paper forms by a nurse and later keyed into this comm ™ lcat ™s server. 

common database. Similarly, when patients undergo testing, 11 15 aDotner ob J ect of the present invention to minimize 
the test results were manually keyed into the common t ? e data necessarv for transmission by synchronizing opera- 
database and/or written on forms stored in the patient's ^ eadl handheld unit and a corresponding corn- 
paper file, munications server, such synchronization including the 

An alternative example lies in the insurance industry in 5 ° mi °"* ization of header information for each transmission 

which field claims adjusters travel to the site of an insurance f nd * he transmisslon of a command case code used directly 

claim and evaluate the damaged property. These adjustors by . cornrnand to aCDess a designated database, 

fill out multiple forms identifying the damage and the 11 ^ arjotner object of tbe present invention to provide a 

insured person's general information. For instance, in an 55 user interface which minimizes user error, 

automotive accident the claims adjustor must describe each ^ ^ another object of the present invention to provide a 

problem with the insured car, such as dents, scratches, and user interface which utilizes an event driven architecture to 

the like. These forms are later processed manually or keyed allow data entry through a touch pad. 

into a common database, after which, the claimant ulti- It is another object of the present invention to provide a 

mately is paid. 60 user interface which is easily operated by using a touch pad 

A substantial amount of data acquisition and retrieval is which presents a scroll bar, rolling keys and icons for data 

also utilized in factory environments. During the course of entrv - 

manufacturing various products, floor workers and quality It is another object of the present invention to provide a 

review must complete multiple forms concerning a given user interface which allows for the scanning of bar codes to 
production unit. 65 identify particular customers or products. 

However, every business requiring significant amounts of These and further objects will become more apparent 

data acquisition and retrieval in its day-to-day business from the drawings and detailed description hereafter. 
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BRIEF DESCRIPTION OF THE DRAWINGS remote communications server 12 interactively communi- 

The objects and features of the invention noted above are J** 1 ° DC ° r h , andheU ^ 8 while 

explained in more detail with reference to the drawings, in • , [ Wlttlm a P rcdefi ? ed K &° a 5 Parnate thereto. This 

which like reference numerals denote like elements, and in comlmlnlca . U ° n * conducted through a wireless 

which: 5 dedicated communication channel, such as upon an infrared 

carrier signal. 

FIG 1 is a block diagram of an overview of a data The communications server 12 controls all interaction 

acquisition ana retrieval system according to the present between the handheld interfaces 8, the command servers 14, 

and the communications bus 6. The command servers 14 

FIG. 2 illustrates a block diagram of a handheld interface 10 control direct access to the databases 16. The command 

according to the present servers 14 may implement any conventionally known 10 

FIGS. 3(a), 3(b), 3(c), and 3(d) illustrate exemplary management system, such as Pro-Tree (version 2.0), SQL or 

display screens shown on the handheld interface according Paradox, The communications server 12 communicates with 

to the present invention; each handheld interface 8 through a unique communications 

FIG. 4 illustrates the main processing loop by which the 15 P rotoco1 (hereafter referred to as the HandheldnServer 

handheld interface monitors and responds to events selected Protocol). The communications server 12 communicates 

by the user; with- the command servers 14 through a unique protocol 

FIG. 5 illustrates the processingisequence of the handheld ( he f ^ ter ^ferred to as the Message List Protocol), 

interface while displaying a patient information screen; . M explained below, the communications server 12 syn- 

mr a im 1C h-^c th. w * f <u u aI ^ 20 chronizes its operations with those of the handheld inter- 

FIG. 6 llustrates the processing sequence of the handheld faces 8 to minimize the excess daU nec for 

interface to initiate the patient information screen; transmission therebetween. The communications server 12 

FIGS. 1(a) and 1(b) illustrate the processing sequence of and interface 8 also utilize shorthand code values to identify 

the handheld interface while displaying a patient input constantly transmitted information, such as commands, user 

screen; 25 IDs, database IDs, and the like. By synchronizing operation 

FIG. 8 illustrates the processing sequence of the handheld of the handheld interface 8 and the corresponding commu- 

interface to initiate the patient input screen; nications server 12, the instant system is able to avoid the 

FIG. 9 illustrates the data structure of the packets trans- need to transmit the user ID, time, date, authorization code, 

mitted between the handheld interface and the communica- the ^ durm S ever y transmission, 

tions server; 30 During operation, the user enters data at the handheld 

FIG. 10 illustrates the processing sequence undergone by interfac * *> dat f * transmitted to the communications 

the handheld interface to write data packets to the cornmu- **™V*dA stored internally within the database 16. Data 

nications server* may e entered directly into the communications server 

irrr 11 vn^^Lw *u- ■ u t_- . 12t sim i la ^y s the user may request data previously 

^ illustrates the processing sequence by which the 35 submitted, in which case the communications server 12 

hSS^Sa^' P transmitted from the accesses the corresponding database 16, through the com- 

' mand server 14, and transmits the necessary desired infor- 

FIG. 12 illustrates the processing sequence by which the mation to the requesting handheld interface 8. Throughout 

communication server parses through a short header struc- operation, a backup copy may be maintained within the 

ture within an incoming packet to build the input buffer; 40 master server 2 for every remote database 16. Additionally, 

FIG. 13 illustrates the processing sequence by which the the user may request, via the handheld interface 8, data 

communication server parses through a long header struc- stored within a remote input unit 4 other than the data in the 

ture within an incoming packet to build the input buffer; databases directly connected to the receiving communica- 

FTG. 14 illustrates the processing QUEUE sequence to iions ser Y er } 2 - m such a circumstance, the corresponding 

move completed messages to the processing QUEUE; 45 communications server 12 would accept the request from the 

FIG. 15 illustrates the processing sequence by which the interface 8, determine that the desired information 

communication server generates the processing queue- B stored w ithm a remote database and request such infor- 

n/i 1£ tl . , ui i j- „ / „ mation through the communications bus 6 from the com- 

th ^ Ah m^- I^if S 8 diagram of the RAM section of munitions server 12 containing the corresponding data- 

tne nandtield interlace; 5Q base ^ the communications bus 6 ^ allows data tQ ^ 

FIG. 17 illustrates a block diagram of the communications transmitted between communications servers 12 and 

server; between handheld interfaces 8 (such as when one doctor is 

FIG. 18 illustrates an alternative data entry display for the requesting information from another doctor), 

handheld interface; and By way of example only, the instant acquisition/retrieval 

FIG. 19 illustrates the processing sequence of the com- 55 system 1 may be utilized within a healthcare facility wherein 

mand server to process and transmit message lists. doctors, nurses, and staff utilize the handheld interfaces 8 to 

record and obtain patient information. These persons may be 

DETAILED DESCRIPTION OF THE assigned different privileges which would allow varying 

INVENTION levels of access to data. In this environment, each commu- 

u^ ie T n 60 mcations server ma y he located within a different ward or 

HG. 1 illustrates a data retrieval/acquisition system testing laboratory. Thus, a doctor in a general ward may need 

according to the present invention generally illustrated by to send a message to, or obtain information from, a doctor 

the reference numeral 1. The instant system 1 includes a or nurse in radiology To do so, the doctor would transmit a 

master server 2 which communicates with multiple remote request through the handheld interface 8, with the request 

input units 4 through a communications bus 6. Each input 65 being received and decoded in the general ward's cornmu- 

unit 4 includes a communications server 12 directly con- nications server 12. The source/receiving communications 

nected to a command server 14 and data bases 16. Each server determines the appropriate destination communica- 
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tions server that corresponds to the destination handheld 
interface, into which the destination doctor or nurse has 
signed on. The desired message is transmitted to the radi- 
ology server, and to the corresponding handheld interface 
which queries the user through audio, video, or vibrating 
means. In a similar manner, the user within radiology may 
transmit a response through the corresponding radiology and 
general ward communications servers 12 to the requesting 
doctor's handheld interface 8. Also, lab data may be quickly 
transmitted to a surgeon during an operation, 

Hie instant acquisition/retrieval system 1 also allows 
doctors, nurses, and staff members immediate access to 
clinical data, even after clinic hours are closed. To do so, the 
user merely enters a request through his/her handheld inter- 
face 8, which is transmitted through the corresponding 
communications server 12 to the clinical communications 
server 12. The necessary clinical data is obtained from the 
clinical database and returned along the communications bus 
6. By way of example, the data acquisition/retrieval system 
1 of the healthcare facility may be connected to similar 
systems via an ethernet connected between the master 
servers 2. 

The handheld interfaces 8 are used to enter all patient 
information such as personal information upon admittance, 
past medical histories, vital statistics throughout their stay in 
the hospital, and the like. For instance, these vital statistics 
may include systolic, diastolic, pulse, temperature, and 
respiratory information. Similarly, the handheld interface 8 
may be used to enter information concerning the patient's 
fluid intake and output. 

As will be explained below, the instant data acquisition/ 
retrieval system 1, also allows a user to carry a handheld 
interface 8 between regions (see the dashed line 5 in FIG. 1) 
dedicated to each communications server 12. Optionally, 
when this occurs, the handheld interface 23, is considered to 
have signed off with the old communications server (as 
illustrated by the dashed line 22). Thereafter, the handheld 
interface 23 must be signed onto the new communications 
server (as illustrated by the line 24) before it may be used for 
data entry. 

The manner by which these objects and functions are 
achieved will become clear in connection with the following 
explanation of each module of the present invention. 
Handheld Interface 

FIG. 2 generally illustrates a block diagram of a handheld 
interface 8 having a display screen 30 which may be 
back-illuminated and which is controlled by a CPU 32 to 
display desired information thereon. The display screen 30 
also functions as a touch pad and is sensitive to user contact. 
When contacted, the display screen 30 outputs a signal to the 
CPU 32 identifying the exact location of the contact there- 
with. The handheld interface 8 further includes a memory 
module 34 which stores software to control processing of the 
CPU 32 and which temporarily stores data received from, 
and transmitted to, the corresponding communications 
server 12. The CPU 32 controls an IR interface 36 to control 
data transmissions to and from the communications server 
12. Abar code reader 37 is included to allow the user to enter 
customer or product information from a bar code, such as 
customer/patient ID and the like. 

As explained below, the handheld interface 8 operates as 
an "event driven" device wherein the touch screen 30 is 
drawn to display a desired arrangement of virtual regions. 
Each region is assigned a unique identifier. The handheld 
interface 8 recognizes each contact by a user as an event. 
The contact/event is recognized with respect to the corre- 
spondingly defined region and the region identifier is 
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returned. Thereafter, the CPU 32 identifies the necessary 
course of action based upon this identifier 

As illustrated in FIG. 3, during operation the CPU 32 may 
display a variety of menus, graphs, and the like upon the 
5 touch screen 30. Within each display, the CPU 32 defines 
virtual regions which correspond to predefined processing 
sequences. The user initiates a desired event sequence by 
contacting the preferred region corresponding to the event. 
To facilitate the user interaction therewith, the CPU 32 
10 provides multiple manners in which the user may enter and 
retrieve data. As illustrated in FIG. 3(c), the CPU 32 draws 
a main menu 38 on the screen 30 and defines multiple menu 
selections 40 therein (see the flowchart of FIG. 10). Each 
menu selection 40 overlays and corresponds to a virtual 
15 event region 42 corresponding to a different event/case. 
Every screen 30 is displayed with an escape key 43 which 
allows the user to escape back to a previous function/screen 
or back to the main menu. 
When implemented in a healthcare application, as illus- 
20 trated in FIGS. 3fl-3d\ when the user selects a vitals event 
region 44, the CPU 32 recognizes it as such and processes 
a corresponding event sequence (see FIG. 13). 

As illustrated in FIG. 3c, the vitals input screen 60 (also 
referred to as the data I/O screen) displays current patient 
25 information in the patient field 62, such as the patient's 
name, social security number, status, and the date upon 
which the vitals were last updated. The vitals input screen 60 
illustrates the last current vitals (data sets) as shown in the 
systolic field 46, diastolic field 48, pulse field 50, tempera- 
30 ture field 52, and respiratory field 54 (collectively referred to 
as data fields). The touch screen 30 allows the user to 
activate a desired vital sign field by selecting a correspond- 
ing icon 46, 48, 50, 52, and 54, respectively. Located 
immediately above each icon is the current value for the 
35 corresponding vitals field. This current value is also dis- 
played within three rolling keys along side of the icon (the 
rolling keys are designated by the reference numeral 56). 
The patient's systolic vital sign field is active in FIG. 3c, as 
evidenced by the inverted rolling keys 56. Proximate the 
40 rolling keys 56 is a scroll bar 58 for illustrating in a bar 
format the current value of the active vital sign field (i.e., 
systolic) which is inverted to the current level (130). 

To enter new patient vitals, the user may do so in multiple 
ways. First, the user may update the patient's systolic vitals 
45 by consecutively contacting each rolling key 56 to be 
incremented. Each rolling key continuously increments, 
such as from 0 to 9 and then back to 0. Alternatively, the user 
may enter patient vitals information by contacting the scroll 
bar 58 at the desired position. In accordance with the 
50 flowchart of FIG. 13, when the user contacts the scroll bar 
58, the bar is updated to reflect the newly entered value. If 
the user drags his/her finger along the scroll bar 58, the CPU 
32 will continuously update the level thereof to reflect this 
movement of the finger. The CPU 32 updates the corre- 
55 sponding rolling keys 56 for the active field (i.e., the systolic 
field as illustrated in FIG. 3(c)). The user may drag his/her 
finger across the scroll bar 58 until the desired value is 
displayed in the rolling keys 56, at which time the user 
releases the scroll bar. The user may activate a different vital 
60 sign field (i.e., change the mode) by selecting the corre- 
sponding icon (46, 48, 50, 52, and 54). 

The vitals input screen 60 further includes change func- 
tion keys 64 which afford the user's direct access to displays, 
graphs, screens and the transmit function. More specifically, 
65 the vitals input screen 60 allows the user direct access to the 
fluids input screen (not shown) for the current patient by 
pressing the fluids function button 66. Alternatively, the user 
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may view the selected vital sign field (e.g., systolic field) in FIG. 15 illustrates the RAM section 35 of the memory 

a graph format by selecting the view graph button 68. The within the handheld interface 8. The RAM memory 35 

vitals input screen 60 further includes a transmit information includes a patient information section 200 for storing a list 

button 70 which the user selects once a patient's new vital D f patient names (data set headers) and patient identifiers 

information has been entered. When the transmit button 70 5 (data ^ identifiers) associated with the present user of the 

has been pressed the CPU 32 transmits the updated patient handheld ^ ^ ^ e RAM memor / 35 also mcludes a 

Sc^bcL C— mCaUODS SCrVeF 12 m 3 f0nnat working space 202 for storing all other information entered 

FIG. m illustrates a graph corresponding to the present W t ^ r transmitted bet ™? ^ ^dheid interface 

patient's systolic vitals which is displayed then the view 8 and ^ co ^mcations server 12. Each time the CPU 32 

graph button 68 is selected. 10 transrmts a request to the communications server 12 for 

FIG. 3(d) illustrates a patient inquiry screen 74 selected P atie nt information, the CPU 32 redefines the current data 

from the main menu 38 (also referred to as the data set structure within the working space 102 to correspond to the 

inquiry screen). The patient inquiry screen 74 displays a expected format of the return data from the communications 

scrolling text window 78 which exhibits the currently server 12. 

selected patient's name (data set header) and those names 15 By way of example only, when the CPU 32 requests 

alphabetically proximate thereto. Along one side of the patient vitals, it expects the returned data to include, in a 

scroll text window 78 is positioned a scrolling bar 80 which preset order, the patient's social security number, date on 

includes an identifier 82 designating the position of the which the patient vitals were last updated, and the most 

currently selected patient's name within a master alphabeti- recent systolic, diastolic, pulse, temperature and respiratory 

cal list. The user may scroll through the patient list by 20 values. The CPU 32 sets up fields within the working space 

contacting the scrolling bar 80 at a desired location therea- 202 for each of these values. When the returned data is 

long. The top and bottom of the scrolling bar 80 corresponds received, the CPU 32 parses through the returned packet and 

to the beginning and end respectively, of the fist of patient assigns bytes therefrom to the desired field in the working 

names stored within the handheld interface 8. space 202 

The padent inquiry screen 74 also includes a virtual ^ The RAM 35 further includes a temporary buffer for 

patient's name, the CPU 34 automatically performs a search are t0 be tr t aasmitted % ^ ^ are received from the 

upon the entered letters and updates the scroll text window f^^^^ 1 ^ ^fl™™ ^ ^ the 

78 correspondingly. As the user enters additional letters, the RAM ? 5 . mto the tem P orar y 204 immediately before 

CPU 32 concatenates these letters to the end of the search 30 transmiUm e ^ information and adds a packet header 206 

string it uses and again updates the scrolling text window 78 . hereto . 

The patient inquiry screen 74 also includes function buttons FIGS - 4-8 illustrate the processing sequence by which the 

64 along a bottom thereof to allow the user to automatically cpu 32 controls the main menu, vital sign patient/data set 

jump to an alternative screen. A scan button 77 is included i^P^t screen and the patient information screen (FIGS, 

to allow the user to read bar code data from a patient's wrist 35 &7-3c/). 

band, such as patient ID. Generally, during operation the CPU 32 loops through one 

FIG. 18 illustrates an alternative scroll bar implementa- of two primary case/event handling loops (FIG. 4). The first 

tion which may be used to allow the user to enter alphanu- case/event loop operates to draw the main menu (FIG. 3a) 

meric information. For instance, the CPU 32 may control the and to handle events chosen from the main menu. When an 

display screen 30 to illustrate a display field 90 and one or 40 event occurs which corresponds to a defined key region 

more scroll bars 92. The scroll bar 92 may be defined such within the main menu, a corresponding event identifier is 

that one end corresponds to the letter A while the opposite returned as the calling identifier. A return code is set equal 

end corresponds to the letter Z. The CPU 32 would define to this calling identifier and the return code is checked 

multiple regions along the length of the scroll bar 92, each against a predefined value (0). If the return code is non-zero, 

region corresponding to one letter of the alphabet. When the 45 processing flow enters the second primary loop to call the 

user contacts the scroll bar 92, a letter corresponding to the corresponding event handling function. The second primary 

touched regions is displayed in a first location 94 of the loop corresponds to processing in which a menu other than 

display field 90. the main menu is displayed (FIGS. 3b-3d). During this 

As the user drags his/her finger along the scroll bar, the second loop, a code which identifies the next function to be 

letter displayed within the first location 94 will vary corre- 50 performed is continuously checked. When the code equals 

sponding to the currently selected region. Once the user zero, processing returns to the main loop. When the code is 

removes his/her finger from the scroll bar 92, the last a nonzero value, the corresponding function is called. Once 

identified region is designated as the correct letter and each function is completed it returns a code identifying the 

entered in the first location 94 of the display. When the user next function to be performed by the user. This configuration 

again contacts the scroll bar 92, the CPU 32 operates to 55 reduces the memory requirements by reducing the Levels of 

display a corresponding letter in the second field location 96 functions to be called, thereby reducing the necessary stack 

of the display field 90. space. 

If it is desirable to enter numerals within the display field FIG. 4 generally illustrates the processing undergone by 

90, the CPU 32 may also draw a second scroll bar 98 upon the handheld interface 8 when the user initiates the first 

the display screen 30. The first end of the second scroll bar eo session (i.e., when the user first logs in). When a session is 

would represent a 0 while the second end of the scroll bar 98 initiated the handheld unit prompts the user for the user's ID 

would represent a 9. The user would enter numerals in the and password (step 1602). Next, a packet is constructed in 

display fields 90 in the same manner as discussed above with the temporary buffer 204 which contains a long header 206 

respect to letters. Optionally, a single scroll bar may be structure and has a data section including the user ID and 

provided for letters and numerals with function buttons 100 65 password (step 1604). This packet is transmitted (step 1606) 

and 101 being used to assign letters or numerals to the scroll and a validation code therefor is waited upon. If the vali- 

k ar * dation code is not received (step 1608) processing returns to 
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step 1602 in which the user is reprompted for the ID and The event identifier is passed to a case/event statement 

password. If a validation code is received, processing con- which includes every possible valid value for the event 
tinues to step 1610 in which a return code is set to indicate identifier. By way of illustration, processing will continue 
that processing should move to the patient inquiry module. along one of six possible processing paths to blocks 1724 
Thereafter, the return code is tested to determine whether it 5 1726, 1728, 1730, 1750 or 1756, depending upon which 
equals zero (step 1623). If the return code equals zero, event occurred. When event 1724 occurs (i.e. the user 
processing returns to step 1614 in which the main menu is presses, the escape icon), the system returns a zero calling 
red ^ wn ' . . . identifier to the main loop (thereby indicating that no new 

Alter this initial login sequence is completed, flow enters event handling function has been selected). If the event 
the main event handling loops. First, a main menu is drawn 10 indicates that the user has touched the scrolling bar 80 
and key regions therein are defined in steps 1612 and 1614, processing flows to box 1726 in which the system deter- 
after which the system waits for an event to occur (step mines the exact location of the event (step 1732). This 
1616). Once an event occurs, it is determined whether the location is correlated with a pointer that is used as an index 
event is within a defined menu regions 42 (step 1618) (i.e., into the patient list to identify the newpatient to be displayed 
whether the user has touched the display screen 30 at a 15 in the scrolling text window 78. Once the event location 
location corresponding to a menu selection 40). If not, is-determined, the pointer into the patient list is updated and 
processing loops back to wait for the next event. If so, an the scrolling text window 78 is redrawn to display the name 
event identifier is obtained for the key region in which the of the selected patient and a limited number of patient names 
event occurred (step 1620). Next, an event handling function surrounding the selected name (step 1734). 
corresponding to the event identifier is called (step 1622). 20 Next, the scrolling bar 80 is updated to move the identifier 
Thereafter, processing waits for a call identifier returned 82 to a new position identifying the relative location of the 
from the called event handling function. Areturn code is set indexed patient within the overall patient list (step 1736). 
equal to the call identifier (step 1623) and the return code is Thus, if the first patient is selected, the identifier 82 is 
tested m step 1624 and if zero, processing returns to the redrawn at the top of the scrolling bar 80, and if the last 
initial step 1612 to redefine and redraw the main menu, If the 25 patient is selected, the identifier 82 is drawn at the bottom of 
return code does not equal zero, the process determines that the scrolling bar 80. If the event is identified as occurring 
the user has selected another function besides displaying the within the scrolling text window 78, processing flows to step 
main menu. Thus, the event handling function correspond- 1728. Specifically, the location of the event is again identi- 
ing to the non-zero return code is called (step 1626). fied (step 1738) relative to the names currently displayed. 
Thereafter, the main event handling loop waits for the called 30 The name closest to the event is identified as the selected 
function to return a call identifier which is tested in step patient. Thereafter, the pointer into the patient list is updated 
1624 * to index the newly selected patient name (step 1740). This 

FIGS. 5 and 6 illustrate the process undergone when the name is displayed in the center of the scrolling text window 
patient information screen 74 is selected to be displayed and, optionally, may be inverted in color (step 1740). The 
(such as during the wake up function or when called by the 35 identifier 82 within the scrolling bar 80 is also redrawn to 
user). First, an initialization routine is called in step 1700 properly identify the new position of the selected patient 
(steps 1710-1720 in FIG. 6). This initializing process begins within the patient list (step 1740). 

by determining whether the handheld interface 8 includes a If the keypad 76 is touched, processing flows to block 
list of patient names (data set headers) and IDs (step 1710). 1730, at which the letter is identified which corresponds to 
If this list does not exist (such as when the handheld 40 the region touched (step 1742). This selected letter is added 
interface has initially been woken up), the unit constructs to a temporary patient searching string within the work 
and transmits a packet to the communications server 12 space memory 102 (step 1744). This letter is added to a 
requesting the patient list associated with the currently search string (which is empty until the first letter is selected), 
signed-in user (step 1712). The communications server 12 Thereafter, the processor conducts a search based- upon the 
receives this packet, identifies the user ID, and requests the 45 search string into the patient list to identify the name most 
appropriate information from the command server 14. closely corresponding to the letters) selected from the 
Thereafter, the appropriate database 16 is read and the virtual keypad 76 (step 1746). If a search string exists (i.e., 
patient list for the user is transmitted back to the handheld the user has already entered some letters) the newly selected 
interface 8. After the interface 8 sets up the data structure in letter is concatenated onto the search string and a new search 
the patient memory 200 for the patient list (step 1714), it 50 is conducted upon the text strings within the patient fist to 
waits for the returned patient list (step 1716). Once the find the first text string which is greater in alphabetic value 
patient list (name and ID) is received, it is stored in the than (i.e., closest to) the search string. The pointer is set to 
patient memory 200. the closest patient name and the scrolling text window 78 

The handheld interface 8 may not include sufficient and the scrolling bar 80 are updated (steps 1746 and 1748). 
display space in the scrolling text window 78 to show an 55 If the user wishes to delete a letter from the search string, 
entire patient's name. Thus, the patient memory section 200 he/she simply pressing the delete region key. 
will only include sufficient memory to store the maximum If the user selects the scan region 77, processing flow 
number of characters which may be displayed for a single moves to block 1750. The bar code scanner is read to obtain 
patient name upon the screen. Once the patient list is stored, the bar code scanned by the user (step 1752) (this bar code 
the patient screen format is displayed (step 1718) as iflus- eo may appear on a patient's wrist band and the like). The bar 
trated in FIG. 3d. Next, the patient names are displayed in code includes the patient ID, which is used to find the patient 
the scrolling text window 78 (step 1720) (FIG. 3d). When name within the patient list (step 1754). Next, the pointer 
the patient fist is too long to be completely displayed within into the patient list is updated (step 1756) and the scrolling 
the scrolling text window 78, a default portion thereof is text window 78 and scrolling bar 80 are redrawn (step 1758). 
displayed. Next, the system waits for an event (step 1722, in 65 Once the user has selected a desired patient, the user may 
FIG. 6) and when one occurs, an event identifier is assigned escape from the patient inquiry screen by pressing the 
thereto. escape icon 43 in the upper left corner or by selecting one 
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of the function 64 buttons at the bottom of the screen (step 
1760). As illustrated in FIG. 3d, the user may escape to the 
main menu, review a patient's information complete record 
or review the patient's vitals. If the user presses one of the 
change function buttons 64 at the bottom of the screen, the 5 
corresponding event identifier is evaluated to determine 
which function key the user has selected (step 1762) and the 
corresponding return code is returned to the main processing 
loop in FIG. 16 (step 1764). 

FIGS. 7a, lb and 8 illustrate the processing sequence 10 
undergone by the handheld interface 8 when the vitals/data 
input/output handling function is chosen (i.e., when a user 
desires to enter patient vitals). First, the display screen is 
cleared (step 1800) and the vitals (data I/O) format is drawn 
upon the screen (step 1802). Similarly, the key regions are 15 
defined which correspond to each even identifier. Next, it is 
determined whether the workspace memory contains vitals 
for a selected patient (step 1804). If not, the processor 
constructs and transmits a packet (step 1806) requesting 
patient vitals. Thereafter, the workspace memory 202 is set 20 
up in the data structure corresponding to patient vitals (step 
1808). Thereafter, the handheld interface waits for the 
returned patient vitals, receives these vitals in one or more 
packets and disassembles the packets and stores the patient 
vitals in the workspace (step 1810). Next, the processor 25 
draws the patient vitals onto the screen (step 1812) and sets 
the default mode to a predetermined field (e.g., systolic 
field). The vitals for the default field are drawn into the scroll 
bar (step 1814) and the default rolling keys 56 correspond- 
ing to the default field are inverted. Thereafter, the handheld 30 
interface waits for an event to occur (step 1816 in FIG. Id) 
and when it occurs, identifies the event number correspond- 
ing thereto. 

Processing flows along one of six paths depending upon 
which event number is identified. While each field upon the 35 
vitals screen corresponds to a separate event number, the 
events as displayed in FIG. 8 may be grouped into six 
general categories, namely, touching a roll key, touching the 
icon, touching the scroll bar, touching the patient's general 
information, touching the escape key, and touching the 40 
change screen buttons (blocks 1818, 1830, 1840, 1852, 1858 
and 1864). Once the event number is identified as corre- 
sponding to a rolling key 56, it is determined whether the 
touched rolling keys are active (step 1819). If not active, 
processing returns to step 1816. If active, a pointer is 45 
determined which identifies the field within the workspace 
memory 202 which corresponds to the specific roll key/vital 
sign selected (step 1820). 

Next, the data value identified by the pointer into the 
workspace is incremented by a 1, 10, 100, etc. depending 50 
upon the rolling key which was touched (step 1822). Thus, 
referring to FIG. 3c, if the user presses the center rolling key 
corresponding to the systolic field, the systolic data value 
within the workspace memory will be incremented by 10. 
Similarly, if the diastolic field is selected and the user 55 
presses the leftmost rolling key therein, the processor will 
increment the diastolic data value within the workspace 
memory by 100. Next, it is determined whether or not the 
incremented value has created an overflow and if so, the 
incremented digit is rolled-over (step 1824). This rollover 60 
function is performed to rotate a rolling key having a current 
value of 9 to a new value of 0. 

Thus, if the user selects the pulse vital and contacts the 
"Is" rolling key (which has a present value of 9), the 
processor will update the pulse value within the workspace 65 
memory to "80". Thereafter, the new vital sign is drawn into 
the rolling keys 56 which have been updated and the new 
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vital sign is stored in the corresponding field in the work- 
space memory (step 1824). Finally, the processor updates 
the scroll bar 58 to reflect the change in the current data 
value (step 1826). 

If the event identified in step 1816 corresponds to an icon, 
processing proceeds to step 1830. First, the rolling keys are 
deactivated for the previously active vital sign field (step 
1832) and the rolling keys for the newly chosen vital sign are 
activated (step 1834). Next, the rolling keys for the deacti- 
vated and newly activated vital sign fields are inverted to 
display the newly active field to the user (step 1836). 
Thereafter, the scroll bar 80 is redrawn with parameters, 
ranges and current vital signs corresponding to the newly 
selected vital sign field (step 1838). 

When the identified event corresponds to touching the 
scroll bar 80, process flows to step 1840. Once the scroll bar 
is touched, the exact location of the event is determined 
therein and used to identify the corresponding vital sign 
value (step 1842). Then, a pointer is determined which 
identifies the vital sign data value within the workspace 
memory which corresponds to the active vital sign field (step 
1844). This vital sign data value is updated to the new vital 
sign value selected within the scroll bar (step 1846). 
Thereafter, the active scroll keys are updated with the new 
data value (step 1848) and the scroll bar is inverted to reflect 
the new data value (step 1850). When the event occurs 
within the patient information region, processing flows to 
step 1852. In such a case, the patient information screen is 
redrawn. To do so, a calling identifier is set to correspond to 
the patient information screen (step 1854) and control is 
returned to the main loop (step 1856). 

Optionally, when the user touches the patient information 
region, a pop-up window may appear and query the user as 
to whether it is desirable to go to the patient information 
screen or enter a patient identifier through the bar code 
reader. In either case, if the user touches the patient infor- 
mation region, before new patient vital signs have been 
transmitted to the communication server, the user is 
prompted as to whether or not these vital signs should be 
transmitted. When the escape icon is touched, processing 
flows to step 1858, after which the calling identifier is set to 
zero (step 1860). Processing is returned to the main loop 
(step 1862). 

If the screen changing buttons are touched, processing 
flows then to step 1864, after which the selected button is 
determined (step 1866). In step 1867, it is determined 
whether the event corresponds to the transmit button. If the 
selected button corresponds to the transmit button, the 
current patient vitals are constructed into a packet format 
and transmitted to the communication server 12 (step 1868). 
If the selected button does not correspond to the transmit 
button, the calling identifier is set equal to the newly selected 
screen (step 1870). Thereafter, control is returned to the 
main loop (step 1872). 

When the return code within the main loop is set to 
correspond to the view graph display screen (FIG. 3d), the 
processor determines the active vital sign field (e.g., systolic 
field), and obtains the corresponding default parameters for 
the graph. Thereafter, the screen is cleared and a graph 
having the parameters for the active vital sign field is drawn. 
Next, the vital sign data values for the active vital sign field 
are read from the workspace memory and used to draw the 
graph. 

Optionally, in the view graph screen a series of changing 
function buttons may be displayed along the bottom thereof. 
These buttons would allow the user to automatically select 
another vital sign to view in a graph format without inter- 
mediately returning to the vital input screen. 



06/05/2003, EAST Version: 1.03.0002 



US 6,571,294 B2 
13 14 

In accordance with the above procedure, the handheld more data exists to write to the buffer (step 414). If no more 
interface 8 allows for user inputs and displays patient data exists, it transmits the packet. If more data exists it 
information to the user. again writes to the packet. In step 416, it is determined if 

Interface-Server Protocol more data exists, and if not it exits. If so, the packet number 

Once the user enters the desired data and wishes to send 5 is incremented (step 418). Next, the CPU 34 constructs a 
this data to the communications server 12, the user presses partial short header for the second frame to be transmitted in 
the transmit function button 70. Once the CPU 32 identifies this message (step 420). The partial header includes the code 
that an event has occurred which corresponds the transmit for the corresponding command and the current packet 
function button 70, the main loop (FIG. 4) calls the transmit number. Thereafter, the next segment of data is written to the 
handling function. FIG. 4 illustrates the process by which 10 packet (step 408) and steps 410 through 420 are repeated, 
the CPU 32 transmits data to the communications server 12, Once the last packet is transmitted (step 414) and it is 

As illustrated in FIG. 9, each transmission comprises an determined that no more data remains to be written to the 
information packet 300 of IR signals corresponding to a packet (step 416), the system exits the transmit routine (step 
packet of data, wherein every packet is constructed with the 422). 
same predetermined length (e.g., 128 bytes) and in one of 15 Communication Server 

two formats. This length is software and operative system FIG. 16 illustrates a block diagram of the communication 
definable and may vary. Certain messages transmitted server 12. The communication server 12 includes an IR 
between the handheld interfaces 8 and the corresponding receiver/transmitter 100 which receives and transmits IR 
communication servers 12 comprise an amount of data communication packets from and to the handheld interface 
which is unable to be assembled into a single packet. Thus, 20 8. The IR receiver transmitter 100 operates in conjunction 
m such circumstances the transmitting device segments the with an I/O card 102 to store a packet of information from 
data into a plurality of equal length packets 300 (referred to each communication channel in the corresponding address 
as frames). The series of frames form a message 302. within a temporary buffer 104. Each communication channel 

When transmitting a message the first packet/first frame corresponds to a unique handheld interface 8, For instance, 
thereof is constructed with a header section 304 formed in a 25 the communication server 12 may provide for 128 IR 
long header structure followed by a data field 306. The long channels and thus, the temporary buffer 104 will include 128 
header 304 includes a 4 byte command field 308, a 6 byte buffer locations, with each buffer location having sufficient 
user identifying field 310, and a 4 byte message total field memory to store a complete IR packet 300 (FIG. 9). The 
312. The command field 308 identifies the process to be number of channels is locally definable and may be any 
performed upon the subsequent data, the user ID identifies 30 desired number. The array locations within the temporary 
the user signed into the handheld interface 8 transmitting or buffer 104 store the IR packets in the format transmitted 
receiving the packet 308 and the message total 312 identifies from the handheld interface 8 as described above, 
the total length of the message which wiO follow. This total The communications server 12 further includes an input 
length includes all bytes within subsequent packets 300 buffer 108 which represents a storage space used by the CPU 
corresponding to this specific message 302. Thereafter, a 35 106 when converting packets from the format stored in the 
data field 314 (having 114 bytes in a packet with a 128 byte temporary buffer 104 to message lists with a different format 
structure) follows. to be transmitted to the command servers 14. The input 

If the message includes more data than will fit in a single buffer 108 represents an array, each element of which 
packet, subsequent packets/frames are transmitted. These includes the COM__INFO structure (explained below), 
subsequent packets/frames are constructed with a short 40 Each element of the input buffer 108 array is accessed 
header structure 316 preceding the data segment 318. The based on the device number. Thus, if 128 handheld inter- 
short header 316 includes a 4 byte command 320 and a 4 faces 8 are being used, the input buffer 8 will include 128 
byte positioning packet 322 identifying number to enable the elements. 

receiving device to determine the position of the packet The communications server 12 further includes a message 
within the overall message. Packets containing a short 45 buffer 110 which is utilized to store the actual data for each 
header 316 includes a 1 20 by te data field for a packet formed complete message sent from the hand held interface once all 
with 128 bytes. During transmission, the first packet of each of the necessary packets have been transmitted by the 
message includes a long header 304 structure followed by a handheld interface 8 and reassimilated by the CPU 106 into 
data field, with each subsequent packet within the message a single message. The COM_INFO stored in the input 
including a short header 316 structure followed by a data 50 buffer 108 includes a pointer MSG_From_HH into the 
field. In this manner, the device is able to increase the message buffer to the beginning of the corresponding data 
amount of data transmitted within each packet for long string. Once every packet 300 for a message 302 is received 
messages. The transmitting device need not send the user ID and the corresponding data is stored in the message buffer 
and the message total more than once for a given message and the COM_INFO is stored in the input buffer 108, the 
since the receiving device is able to associate corresponding 55 CPU 106 constructs a message list therefrom. Each message 
packets with a single message 302 based on the packet list to be processed by the command server 14 is stored on 
number 322 and communication channel, one of a process queue 114. The message list includes a 

To transmit a message (FIG, 10), the CPU 32 reads the pointer to the corresponding data string in the message 
current data from the workspace memory 200 in the RAM buffer 110. Each message list received from the command 
35 (step 400). Next, the CPU 32 determines the length of the 60 server 14 is initially stored in a transmit queue 116 prior to 
message and the ID of the user signed in to that handheld being converted back into packets 300 and transmitted to the 
interface 8 (step 402). The CPU 34 constructs a packet handheld interface 8. The message list includes a pointer to 
header formed with the long header structure (step 404). The a corresponding data string which is stored in the message 
CPU 34 clears the packet number (step 406) and writes the buffer 110 when it is received from the command server 14. 
data to the transmit buffer (step 408). If the packet is full 65 The process and transmit queues are operated in a first- 
(step 410), the CPU 32 transmits the packet and clears the in-first-out sequence such that each message is processed or 
buffer (step 412). If the packet is not full, it determines if transmitted in the order in which it is placed in the queue. 
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The transmit and process queues 112 and 114 constitute length (MSG_LEN) is a value updated by the short and long 

dynamic queuing systems which attach message lists in a header parsing functions to keep track of the length of a 

linked hst structure Each message list includes the data message in the message buffer 110 as the packets for the 

structure .Mustrated below: mfSSage „ e added ^ message &M fa 

5 initially tested by the communications server 12 when 
processing each packet in the temporary buffer 104 to 
MESSAGE LIST determine if the packet is in a long or short header form. The 

message pointer field (MSG_From__HH) is a pointer into 



SSX- ? ataFi l e ^ MSG - TO - msg_len Prev the message buffer to the location of the actual data message. 

T ST'SU & 10 The MSG_From_HH pointer is updated each time a new 

packet is appended to a message. 
com_info The message list structure includes the above COM_ 

INFO structure as an addition to a Data_pile field that 



(into- (Long (6) From (Long (Long hh 15 m ? CUM_JN1<0 structure, to be processed in connection 

ger) integer) (6) integer) integer) (Pointer) with the corresponding command. The command (CMD) 

field represents a one byte command, written from the 

The message list data structure includes a first section CO^NFO structure, to be processed. The MS G„To_HH 

COM_INFO dedicated to, and containing information Md ^presents a message pointer used to point to the data 

concerning, messages received from the handheld interface 20 b y the command server in connection with this 

8. The next four fields represent fields which are created messa S e which will ultimately be sent to the handheld 

immediately before transmitting a message list to the com- interface 8. The MSG__XEN field represents a long integer 

mand server 14 and another communications servers 12. The identifying the current length of the data corresponding to 

final field (Previous MSG__LST) is used as a pointer to the tne message and stored in the message buffer. The 
subsequent message hst within the queue to be processed, 25 Previous_MSG_LST represents a pointer pointing to the 

The first section COM_INFO includes a device number next message to be processed. The previous message pointer 

uniquely identifying the handheld interface transmitting the enables the system to accomplish dynamic queuing for the 

message. The device number is generated by the I/O card process and transmit queues. 

102 when the CPU 32 requests a packet 300 from the FIG. 11 illustrates the processing sequence by which the 
temporary buffer 104. The device number is produced 30 communication server 12 receives messages from the hand- 
depending upon the communications channel being held interface 8, processes these messages and transmits 
accessed. The command (CMD) includes the structure of the these messages to the command server 14. First, the I/O card 
CMD field transmitted in the header of each packet 300 (i.e., 102 is initialized, along with the communication channels, 
the 2 byte database ID, 1 byte command ID, and 1 byte buffers and queues (step 700). Next, the data structures for 
reserved). 35 the message list, COM_INFO, CMD, and short and long 

The command (CMD) represents the command to be headers are set up (step 702). A current channel to be read 

processed in accordance with the corresponding message by the I/O card 102 is initialized to the first channel (step 

being transmitted to or from the handheld interface 8. The 4 704). Next, the current channel is tested to determine 

bytes within the command are separated such that the first whether data is being transmitted thereon from the corre- 

two bytes identify the database to be processed when 40 sponding handheld interface 8 (step 706). If data is present, 

performing the command, the third byte stores a number the packet of transmitted data is read and stored in the 

corresponding to the specific command to be performed, and temporary buffer 104 (step 708). The packet of data is stored 

the fourth byte is reserved. By way of example, with respect within the temporary buffer 104 at the array address corre- 

to the third byte, numerals 1-127 represent commands to be sponding to the current channel. A channel identifying 

processed by the command server, while numerals 128-255 45 number corresponding to the transmitting handheld interface 

represent a command from the handheld interface 8, As 8 is also assigned thereto by the I/O card 102. 

noted above, the use of shorthand code numbers for specific Next, a check sum field within the-data packet is tested to 

commands reduces the amount of data to be transmitted to determine whether the transmitted data is valid (step 710) If 

and from the handheld interface 8. the data is invalid, the communication server takes the 

The Packet Number is a long integer which is incre- 50 necessary corrective actions (step 712). If the data is valid, 

mented each time a packet is appended to a message on the the CPU 106 requests the channel number (step 714) and the 

input buffer 108. The User_ID_To is a 6 byte value added packet 300 from the I/O card 102 and utilizes the channel 

by the handheld interface 8 to identify a destination user. If number to index the correct corresponding element within 

set to zero, the destination is the communications server. The the input buffer 108. Next, it is determined whether a packet 

communications and command servers determine which 55 is an initial frame or a subsequent frame of a message (step 

server to send the command to. This value if non-zero will 716). To effect this test, the message total field, within the 

identify the user of a handheld interface 8 desiring to element of the input buffer 108 corresponding to the current 

communicate therewith. The User_ID_From is a 6 byte channel, is read and compared to zero. If the message total 

value added once at login time. This user ID is assigned to field equals zero, then a packet has not yet been written to 

the channel to identify who is logged in at that channel. This 60 this element of the input buffer 108. Thus, the packet being 

value js maintained until the person signs out. Thus, the user read is identified as an initial packet which will include the 

ID will only be transmitted once during a login session. The long header structure. Otherwise, the packet is identified as 

communications server 12 keeps track of each User ID one containing the short header structure. In either case, the 

signed onto handheld interfaces served by that communica- packet number is incremented within the currently indexed 

tions server 12. The message total length (MSG_Total) is a 65 element of the input buffer 108. 

value assigned by the handheld interface 8 or by the com- If the packet contains the long header structure process- 

mand server 14 when a message is transmitted. The message kg moves to step 718 in which the parse long header 
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function is invoked. If the packet includes the short header the COM„_INFO of the indexed element of the input buffer 

structure, processing moves to step 720 where the parse 108 (step 758). Thereafter, the control returns to the main 

short header function is invoked. process (step 760). 

FIG. 12 and FIG. 13 illustrate the parse long and short Referring to FIG. 11, once control is returned to the main 
header functions. Within the parse long header function, the 5 program, the current channel is incremented (step 760). 

first four bytes of the data packet within the temporary queue Next, it is determined whether all channels have been 

is read as the command (step 722). This command is checked (step 762). If so, control is set to the processing 

compared with a list of valid commands and if the command sequence (at point A). If all of the channels have not been 

is invalid the processor takes the necessary corrective action checked, control returns to step 706. This process is con- 
(step 724). If the command is valid, the command is written 10 tinuously performed until all of the channels have been 

to the command field within the element of the input buffer checked thereby transferring all packets of data from the 

108 indexed by the corresponding channel number (step temporary buffer 104 to the input buffer 108 and message 

726). Next, the subsequent six bytes of the packet within the buffer 110. 

temp buffer is read as the User ID, if present, of the Next, processing moves to the processing queue sequence 
destination user for the attached message/data. This six byte 15 (FIG. 14) to move completed messages 302 to the process- 
ID is stored in the UserID_To field of the element within the ing queue 112, First, the current element pointer into the 
input buffer 108 indexed by the current channel number input buffer 108 is set to the first input buffer element (step 
(step 728). The User ID, corresponding to the signed on user, 800). Then, it compares the message total length (MSG_ 
is added to the UserID__From field of the indexed element. Total) with the message length (MSG_LEN) to determine 
Next, the subsequent four bytes are read from the packet 20 whether a complete message corresponding to the current 
within the temporary buffer 104 as the total length of the element within the input buffer 108 has been received and 
following message (e.g., the total number of bytes to follow stored in the message buffer (step 802). If not, the incom- 
within one or more packets corresponding to the present plete message remains on the input buffer 108 and the 
message) (step 730). The four byte value representing the current element pointer is incremented (step 804) and the 
message total is converted to a long integer (step 732) and 25 process returns to step 802. 

assigned to the message total field within the element of the If the complete message for the current element has been 

input buffer 108 indexed by the current channel number received, the message is placed on the processing queue 

(step 734). Thereafter, the data section within the packet is (step 806) by creating a message list therefor. To do so, the 

written to the message buffer as a data string and the length command information (COM__INFO) of the current element 
thereof is stored within the message length field within the 30 of the input buffer 108 is written to the processing queue 112 

presently indexed element of the input buffer 108 (step 736). and stored in the command information (COM_JNFO) 

A message pointer pointing to the data string within the section therefor. As the corresponding message represents a 

message buffer 110 is stored within the message pointer field transmission from the handheld interface 8 to the command 

of the indexed element within the input buffer 108 (step server 14, the next four fields of the indexed message list 
738). Finally, the element of the temporary buffer 110 is 35 element in the processing queue remain undefined. This 

cleared (step 740). In this manner, steps 718-740 parse message list is "pushed onto the back" of the processing 

through a packet having a long header structure, create the queue by storing, in the preceding message list in the 

COM_INFO structure within the input buffer 8 and store the processing queue, a pointer to the current message list. This 

message 302 from the handheld interface 8 within the pointer is stored in the final field (Previous_MSG_LST) 
message buffer 110. 40 within the previous, most recent message list added to the 

Returning to FIG. 11, if in step 716 it is determined that processing queue (step 806). 

the packet is not an initial packet, then the short header Once the command information has been moved to the 

function is invoked (see FIG. 13). First, the first four bytes processing queue, the corresponding element of the input 

of the packet are pulled (step 742) and compared with the buffer 108 is cleared (step 808). Thereafter, the current 

value in the command field of the currently indexed element 45 element pointer into the input buffer 108 is incremented 

within the input buffer 108 (this command is indexed based (step 810) and it is determined whether or not every element 

on the channel number) to determine if these commands are of the input buffer 108 has been tested (step 812). If not, 

the same (step 744). If not, the system takes the necessary processing returns to step 802 and the next element within 

corrective actions (step 746). If the commands correspond, the input buffer 108 is processed. If processing is done on the 

the packet number within the short header is pulled (step 50 input buffer 108, control moves to process the message lists 

746), converted to a long integer (step 748) and compared to on the processing queue. 

the packet number (plus one) within the indexed element of The first element of the processing queue is tested to 
the input buffer 108 (step 750). These packet numbers must determine whether a command is stored therein (steps 900 
correspond to ensure that the received packet is the next and 902). If a command exists on the processing queue, this 
packet to be added to the input buffer 108. If the packet 55 command is "dequeued" (step 904) by reading the message 
numbers correspond, the present packet is identified as part information from the processing queue (which is stored in 
of the message corresponding to the presently indexed the message list structure). The command field (CMD) 
element within the input buffer 108 and processing flows to within the COM_INFO section of the message list is read, 
step 752, else it returns. If the packet is not matched based The message is parsed into specific components (step 906), 
on above criteria, then a corrective action is taken. 60 by reading the first two bytes of the command field, con- 
Next, the data within the temporary buffer 110 is pulled verting these bytes to a long integer form and storing the 
(step 752) and the portion of the message already stored in data base identifier in the Datajile field of the message list 
the message buffer 110 is read (step 754). The new data is (step 908). Next, the third byte of the command (CMD) field 
added to the end of the stored message and the new total in the COM__INFO structure is read and stored in the 
string is rewritten to the message buffer 110 (step 756). The 65 Command field of the message list (step 910), Then the 
message pointer (MS G_From_HH) and the message length actual data message is appended to the message list structure 
(MS G_LEN) are updated within the corresponding fields of based on the message pointer (MSG_TO_HH) and the 
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message length (MSG_LEN) are reset (step 912). The the command server 14 receives a message (step 900), 

communications server 12 sends the message to the appro- including the complete message list structure followed by 

priate command server 14 based upon the database and the data message. Next, the command server 14 reads the 

command code (step 912). data base file field (step 902) and determines whether that 

Next, the previous message pointer (Previous__MSG_ 5 data base code is valid for the present command server 14 

LSI) is read from the current message list to determine the ( step 904). If not, it returns an error message (step 906). If 

next message to be processed on the queue (step 914) and so , control is transferred to the database routine correspond- 

control is returned to step 902. In this manner, each message ing to the command code (CMD) in the Command field of 

upon the processing queue 112 is parsed through and trans- the message list (step 908). Next, it is determined whether 

mitted to the appropriate command server 14. When no more 10 the command code is correct for the addressed database 

commands are on the processing queue, control is moved to (step 910). If not, it returns an error code (step 906) If so 

the create transmit queue module (step 916) (FIG. 15). it accesses the message data within the message list and 

FIG. 17 illustrates the process by which the communica- performs the appropriate operation upon the data base (step 

tion server 12 processes messages upon the transmit queue 912). Thereafter, it constructs a return message using the 

which are to be sent to the handheld interface 8. First, the 15 data returned from the database into the structure of the 

first message upon the transmit queue is tested (step 1000) message list (step 914) and quits (step 916) 

to determine whether data is contained therein (step 1002). To invoke tne database managing functions, the command 

If data erats the message is dequeued by taking the number is processed within a case statement, whereby each 

message off the transmit queue (step 1004). Next, the case within the case stat e m ent corresponds to a unique 

command information from the message list is read and a 20 command number. Each case statement calls the appropriate 

ong header constructed for the first packet to be transmitted routioes . For command number 7 may represent an 

JjJSS interface 8 for the message (steps 1008 and add command, and thus, case "7" would direct the command 

1009). Next, the data from the message is written to the server t0 read me data from the messa and write this data 

packet and transmitted (step 1010 and 1012). Thereafter, it t o the next address within the database. Similarly the 

* ^^u^x. Wh ? h ?J add i tlona l data 1™™ S to be trans " 25 command number within the message may represent a read 

mitted to the handheld interface 8 (step 1014). If yes, a short or request operation, in response to which, the correspond- 

header is constructed (step 1015) and additional data from in g case would dkecX the command serV er to read the desired 

the message * written to the packet containing the short information from the database corresponding to the user ID 

header (step 1016). transmitted within the message. The command server there- 

Once constructed, the packet containing the short header 30 after adds this data to the messa e and retransmits it to the 

is transmitted (step 1018) and processing returns to step communications server 

10% £ ^ h ^ nlT^ ^ m ° re ^ ™ S From the fore S oi "S a ™ m be «« that this invention is 

oop » repeated until the entire message has been trans- one weU ad ted to ^ ^ ^ md ^ hereinabove 

S^TSw^tf set forth t0 S ether with the other ^vantages which are 

transmitted to the handheld interface 8. Once the entire 35 obvkms ^ which afe inherem tQ ^ 

message has been transmitted, control passes to the next T * -n u j * j u. * • r ^ * 

module fsteo 1020) W understood that certam features and subcombi- 

The communications server 12 tests the communication ^ ™ "ay be employed without reference 

bus 6 and determines if messages have been sent from other *° ^features ™d subcombinations. This is contemplated 

communication servers. First, the communications bus is 40 by and 15 Wlthm the SCOpe ° f the claims " 

tested to see if a message exists (step 1100). If a message Slnce man > P osslble embodiments may be made of the 

exists, the message is read (step 1104) and the command "ivention without departing from the scope thereof, it is to 

therefor is decoded (step 1106). Thereafter, the command is be u^k 15 * 10 ** that a11 matt£ * herein set forth or shown in the 

tested to determine whether the message should be trans- accompanying drawings 1-19 is to be interpreted as 

mitted to a corresponding handheld interface 8 or whether 45 lllustrative > md not m a limiting sense, 

the message should be transmitted to a command server ^ following appendix sets forth descriptions of the 

connected to the communication server 12 (steps 1108 and modules and functions used by the present system. 

1110). Thereafter, the message is placed on the transmit or Glossary 

processing queue depending upon the destination of the key — an area of the screen that has been registered with the 

message (steps 1112 and 1114). Thereafter, control is 50 opening system as an area where an event is expected. If 

returned to the main program (step 1116). This process is an event does not occur within this area, an integer 

continuously repeated until the communication server 12 is identifier will be returned by the operating system indi- 

turned off. Once turned off, the communications channels eating that the event did occur. 

are closed and the system is turned off. event— the screen was touched, if it was touched in an area 

Command Server 55 defined by a key, then return the identifier. 

The command server operates to update the correspond- scrolling text window — a key where scrolling text will 

ing databases based upon messages received from the com- reside. 

munications server. The command server utilizes a conven- scroller — a key associated with the scrolling text window, 

tional software package for managing these databases, such the scroller has a bar in it to indicate where the text within 

as Pro-tree (version 2.0). Other database managing systems 60 the text window is in relationship to the rest of the text, 

may be used to access the data base, such as DBase, scrollbar — the tool used for entering vitals (darkened from 

CodeBase, B-Trieve, Cisam and the like. Particular com- the very bottom of the key to the value chosen by the 

mands within the conventional management system are user). 

called depending upon the command code and database rolling key — a key with a digit in it, when the key is touched, 

codes transmitted within the message list. 65 that digit is incremented. If the digits value is 9 and it is 

FIG. 19 illustrates the process by which the command incremented, it will contain the value 0 with no carry 

server 14 invokes the database management functions. First, performed. 
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Module 2^-faandles all events, 

scrollbar.c — contains all functions for the scroll bar events 

functions to be used by other modules. * n tne casc tna t the user picks A-Z, that letter is concatenated 

init_scroll_bar-initiaUzes all necessary variables and ° nt ° th , e f^** 8 *^ u which is initially empty, then a 

draws all of the detail 5 sec l ueiltial ^arch upon the text strings is performed to find 

draws all ol the detail. the flm ^ wh{ch ^ ^ alphabetical value than ^ 

get_scroll_bar_yalue-^upon an event in the scroll bar search string, then that value is chosen via the function 

key, this routine is called and it handles that event, then set_scroller__value. 

it returns the value that the scroll__bar is pointing to * n mc cvent tne user touches the scroller then 

(the value point pointed to by the user). 10 get_scroller__value is called. 
set_scroll_bar_value— the user can set the value any- ^ ^ event the user touches scrolling text key, then 

time. get__scroll_text value is called. 

functions to be used internally by this module ^f 1 ^ tu» - f t *u 

i m r ii u j *u • *j r *l « 1 vital_l.c — the starting point of the program contains all 

draw scrolLbar— draws the inside of the scrolL_bar. function calls. 

Module 15 note— Every single "screen" that is called from any other 

vital_input — contains all the functions used to perform the "screen" will be associated by a Calling Identifier (Call 

vital input ID), 

note — the Mode value indicates what is being input at the DoMainMenu — two main case statement 

moment, if the user has chosen systolic, then the systolic case statement #1 

rolling keys are inverted and activated, and the scroll bar 20 handles the events of the main menu, if an event occurs in 

will have the systolic data in it. an Y °f the keys of the main menu, then store the CalllD 

possible modes^ystolic, diastolic, pulse, temperature, in the 7f riable <* lled ReturnCode. 

respiratory. case statement #2 

Write^Keys_Data-this routine redraws the rolling keys « ^ ^ r * ^ * ,? u° P ^ ^ s ^™' 

associated with a certain mode, (example, if the mode is * S ^^2* h !f ^TiTTh^ 

pulse and the user somehow changes the value, this V S fhA t 1? H g " 11 \ 11 ^ in ^ 

r™i*i«*^n« w A mn. 1 .1 1 Ct .i ' iTT vanable, the function called will eventually return a code 

routine draws the 100s value m the leftmost key, the 10s that will again be stored in the vanable R * tQ)de 

value in the middle key, and the Is value in the rightmost Module 
key): 

30 scroller.c — contains all functions for the scrolling text win- 

ChangeMode — changes the mode of the screen, this dows. 

involves (1) turning off the old mode (example— pulse); functions to be used by other modules 

(2) turning on the rolling keys of the new mode init_jscroller— initializes all necessary variables and draws 

(example — systolic) so now an event may occur — also of all the detail. 

invert the keys so that they are white on black; and (3) 35 get_scroller_value — upon an event in the scroller key, this 

calling Init_jscroll_J>ar to redraw the scroll bar with the routine is called and it handles that event, then it returns 

new modes details. the value that the scroller is pointing to (in our program, 

EnterVitalsDraw — draw the detail on the entire screen tn * s vanie ^ the index into an array of strings — points to 

(1) write patients name , the te * that was P^O- 

, . j . j 4 , , , An set-scrolier_value— the user can set the value any time 

(2) write last date and time that the vitals were entered 40 get_scroll_text_value— upon an event in the scroll text 

(3) write the last vitals values window, this routine is called and it handles that event, 

(4) turn off all rolling keys tnen ^ returns the same value as does the get_scroller_ 

(5) change the mode to systolic by calling changemode J^to'beused internally by this module 

theiT^N w£ K rff , 10 r ° 1Img - 6yS ' 45 draw_scroller-Klraws the bl Lit of the scroller, then 
then call Write-Keys _ckta mc^emp-same as inc_ calls draw scrolLtext . 

value but allow the 100 s key to contain the values 0, draw.scroll-text-^raws all of the text that appears in the 
1,2,3,4,5,6,7,8,9,10,11. scrolling text window. 

Do.vxtaUinput-raE MAIN ROUTINE invertjicked.text-inverts the text that is being pointed 

(1) calls EnterVitalDraw 50 to by the user. 

(2) contains the case statement that handles events. Major Functions 

Module open__ir — used to initial the IR communication with the 
graph.c— draws the graph on the screen. AndroDat Card and setup the communication channels 

make_graph— receives x,y values, x axis label, y axis label, < e with each device 

the type of data that the x and y values are (time, short int, 55 T ^iTfn communication channels with 

int, long int, float, etc.) and draws the graph, depending . nana . n ^ ld ' 

upon the type of data in x and y, it calls a simpleVoutine ^0*^7^ to reset and clear all data contained 
that turns the x, y values into x, y plotting points on the f 0 ' 0 !? ^f**. °° m >?? ^r This routine is called 

r initially to initialize each buffer and ready to receive data. 

so After a message has been received and put on the process 
queue, this routine is used to clear the old data and ready 
patinput.c— contains all of the functions used to pick a the input buffer for the next command. 

P atlent - collect_messages — this routine will read through each input 
DoPatientlnput— <loes the entire screens functionality within channel to see if a message exists. If one exists, then the 

this one routine. 65 message will be read into a temporary buffer and passed 

1— imt_scroller— passes in the patient list and the two keys to the routine place_message for placement on the input 

(scroller key and scrolling text key). buffer. 



screen 
Module 
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place_jnessage — this routine will determine if the message 
being read is the first or subsequent message. If the 
message is the first packet, then the routine parse_ long_ 
hdr is called. If the packet is the second or subsequent 
message, the routine parse short__hdr is called. 

parse_short_hdr — this routine is used to parse the structure 
tmp__buffer, validate the command being sent along with 
the correct packet number, then place the data in the 
appropriate in__buffer message structure. This routine is 
called after the initial command packet is sent. 

parse„_lon&_hdr — this routine is used to parse the structure 
tmp-buffer, validate the command being sent. This routine 
then initializes the in_buffer structure and finally places 
the data in the in buffer messages structure. This routine 
is called when a handheld device sends its initial packet 
for requesting a command. 

comm_server — this routine is the main routine which con- 
trols the logic flow of the entry communication server 
system. 

process__in_buffer — this routine is used to search the 
in-buffer for completed messages to be placed on the 
process queue. This routine determines if a message is 
finished if msg_total— msg_Jen and msg_total>0. This 
routine calls ENQUEUE to physically put the message on 
the process queue. 

process_cmd — this routine is used to take the next message 25 
off the command queue then send it to the correct server 
for processing. This routine calls the dequeue function to 
physically dequeue the item off the command queue. 

process_transmit — this routine is used to take the next 
message off the transmit queue then send it to the correct 30 
server for processing. This routine calls the dequeue 
function to physically dequeue the item off the transmit 
queue. 

packet_msg — this routine is used to physically send the 
message from the communication server to the handheld 35 
computer via the AndroDat Card. It is responsible for all 
packets of the data and verify of successful transmission. 

enqueue — this routine takes completed messages and places 
them on the queue. A parameter is passed to which queue 
to place the message along with the data to queue. 40 

dequeue — this routine will take messages off the queue and 
place them in a temporary buffer to be processed by the 
communication server. A parameter is passed to which 
queue to process along with the temporary space to put 
message. 

nulqueue — this routine is used to initialize a queue and 
prepare it to start receiving data. Call to this routine will 
destroy any data existing in the queue. 

com_jnfb — this structure is used to store the incoming 
message from the handheld 

in_buffer— this is an array of the structure com__info. This 
structure is used to hold the individual messages being 
received from the handheld computers. 

messagejist — this structure is used to serve as the queuing 
functions for the command processing and data transmis- 
sion. 

long_Jidr— this is the structure of the header for initial 

communication to the server. 
short_hdr—this is the structure for second and subsequent 

communications of the second command. 

What is claimed is: 

1. A bar-code-driven data acquisition and management 
system comprising: 

at least two input computers, operably coupled via a 
communication link, each said input computer being 
coupled to a respective local database of data records; 
and 
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at least two portable computing devices, each said por- 
table computing device being operably coupled to one 
of the two input computers via a wireless communica- 
tion channel for accessing and updating the data 
records in the local databases of the at least two input 
computers, wherein each portable computing device 
comprises: 

a CPU for controlling operation of the portable com- 
puting device; 
memory storing at least one data set, each data set 

having multiple data fields storing data values; 
a touch sensitive display device for displaying at'least 
a data I/O screen and for sensing contact by a user, 
the CPU defining multiple virtual regions upon the 
data I/O screen, each virtual region corresponding to 
a data field, the touch sensitive display device sens- 
ing contact by the user within a virtual region, the 
touch sensitive display device displaying within each 
virtual region a data value for the associated data 
field from a current data set, and the CPU identifying 
a virtual region contacted by the user and effecting an 
interface control associated therewith; and 
an optical scanning device for reading bar codes encod- 
ing data values for data fields corresponding to at 
least one virtual region displayed upon the data I/O 
screen and displaying such data values thereupon. 

2. The bar-code -driven data acquisition and management 
system of claim 1, wherein the CPU of each portable 
computing device executes a graphical user interface that 
includes an event handler, the event handler: 

identifying one of the virtual regions that corresponds to 

the location of user contact, 
determining a specific event identifier corresponding to 

the identified virtual region, and 
processing a predetermined sequence for the specific 
event identifier. 

3. The bar-code-driven data acquisition and management 
system of claim 2, wherein each virtual region of the 
graphical user interface corresponds to a predefined process- 
ing sequence which is initiated by the user by contacting the 
associated virtual region. 

4. The bar-code -driven data acquisition and management 
system of claim 3, wherein the predefined processing 
sequence involves one of a data entry operation, a data 
transmit operation for communicating data stored thereto to 
another computing device, and a code scan operation for 
data entry. 

5. The bar-code-driven data acquisition and management 
system of claim 2, wherein the graphical user interface 
further comprises a virtual keypad displayed on the data I/O 

50 screen for entering symbols associated with keys of the 
keypad. 

6. The bar-code-driven data acquisition and management 
system of claim 2, wherein the graphical user interface 
further comprises at least one scroll bar displayed on the data 

55 I/O screen. 

7. The bar-code-driven data acquisition and management 
system of claim 2, wherein the graphical user interface 
further comprises at least one scroll bar format and a rolling 
key format. 

60 8. The bar-code-driven data acquisition and management 
system of claim 2, wherein the graphical user interface 
further comprises a menu screen and a graphing screen, 
wherein each selection from the menu screen corresponds to 
a virtual region and an associated processing sequence. 

9. The bar-code -driven data acquisition and management 
system of claim 2, wherein the graphical user interface 
displays multiple icons. 
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10. The bar-code-driven data acquisition and management 15. The bar-code-driven data acquisition and management 
system of claim 2, wherein the graphical user interface system of claim 12, wherein communication between a 
comprises a text input mechanism that enables the user to given second server and each portable computing device is 
enter at least a portion of a desired text data, that automati- selected based on the predefined region and position of the 
cally searches data stored in memory to retrieve text data 5 portable computing device. 

closest to the portion of desired text data entered, and 16- The bar-code-driven data acquisition and management 

displays the retrieved text data on the data I/O screen. system of claim 1, wherein the data values encoded by the 

11. The bar-code-driven data acquisition and management bar codes represent information related a medical patient, 
system of claim 1, wherein each input computer comprises* 17, Tbc ba r-code-driven data acquisition and management 

a first server that manages the local database ctmpled to ^f"°j tn^in, ™f ^ ^ V^T T ^ 

thereto- and codes represent one of personal information gathered 

upon admittance for care, information related to past medi- 

a second server for receiving and transmitting packets of cal history of the medical patient, and information related to 

information to and from at least one portable comput- vital statistics of the medical patient, 

ing device over the respective wireless communication 18. The bar-code-driven data acquisition and management 
channels. 15 system of claim 17, wherein the vital statistics include one 

12. The bar-code-driven data acquisition and management of systolic, diastolic, pulse, temperature and respiratory 
system of claim 11, wherein the at least two input computers information. 

are part of a computing tier comprising: 1^. The bar-code- driven data acquisition and management 

a plurality of first servers for managing local databases on System ° f claim wherein . each P ortab i e ^1**"* 

coupled thereto* comprises a message notification mechanism that notifies 

' the user of receipt of a message from one of the input 

a plurality of second servers for receiving and transmit- computers over the respective wireless communication 

ting packets of information to and from the portable channels. 

computing devices, wherein a given second server 20. The bar-code-driven data acquisition and management 

selectively communicates with the portable computing 25 system of claim 19, wherein the message notification 

devices located within a predefined region proximate mechanism generates one of an audio signal, a video signal 

thereto; and and vibration signal, 

wherein the plurality of first servers and the plurality of 2L ^ bar-code-driven data acquisition and management 

second servers communicate one another via a com- systera of claim wherein communication of data between 

munications network. 30 ^ e at * east two P orta ble computing devices occur over the 

13. The bar-code-driven data acquisition and management respective wireless communication channels and the corn- 
system of claim 12, munication link operably coupling the two input computers. 

wherein a given second server is associated with one of 22> ^ ; b »;«^^ acquisition and management 

the plurality of first servers- system of claim 1, wherein the data values encoded by the 

• l * « bar c °des represent product information. 

wherein the given second server interacts with a given 23. The bar-code-driven data acquisition and management 

portable computing device located with a predefined svstem 0 f claim 1, wherein the data values encoded by the 

region proximate thereto to service requests commu- bar codes represent information identifying a medical 

mcated from the given portable computer; and patient. 

wherein, upon determining that one of said requests ^ 24. The bar-code-driven data acquisition and management 

requires access to data stored in a local database system of claim 2, wherein each portable computing device 

associated with a first server other than the one first comprises local memory storing information loaded from 

server, the one request is communicated over the com- the data records of at least one of the local databases via the 

munications network to the other first server to access respective wireless communication channels, 

said data stored in the local database coupled thereto, 4$ 25. The bar-code-driven data acquisition and management 

and said data is returned to the given second server over system of claim 1, wherein each portable computing device 

the communications network for communication to the comprises a graphical user interface for interacting with a 

given portable computing device. user to enter user-supplied information, wherein the user- 

14. The bar-code-driven data acquisition and management supplied information is communicated to at least one of the 
system of claim 12, wherein the plurality of second servers 5Q input computers over the respective wireless communication 
and the communications network therebetween enables channels for storage in the local database coupled thereto, 
communication of data between the portable computing 

devices. ***** 
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